|
|
|
|
|
|
|
expensive and probably goes against much of what you've learned about development projects, but it minimizes the unnecessary risks associated with project scheduling. |
|
|
|
|
|
|
|
|
The Inception Phase for personal projects is much less formal than for corporate projects. Yet it's still a good idea to size up the specific tasks necessary to accomplish your solutions. A model of the business processes affected by the solution you propose provides a common basis of understanding between you, your team members, managers, and your users. |
|
|
|
|
|
|
|
|
Note
When you develop a Visual Basic application for a company, you are developing a tool that enables a worker to accomplish some task that helps complete a business process. A business process is a collection of one or more tasks that provides some value for the company. A business process model represents one or more business processes that interact to carry out a goal. Workers who are responsible for carrying out these processes are task owners, and their manager is the process owner. These personnel are also represented in the business process model. For instance, in a bank, there would be a loan application acceptance and entry process, a loan approval process, and a loan acceptance and delivery process. |
|
|
|
|
|
|
|
|
|
Whether you develop software in-house for a client or commercially as an entrepreneur, you need to understand how the intended user will use the system within his or her environment. Normally, you would conduct this kind of research in the Elaboration Phase of the project. During this phase, not only are you doing domain or market research, but you're also establishing the foundation of your system's application in the least risky manner possible. However, when projects are sensitive to monetary constraints or time-to-market scheduling, you should do domain research as part of Inception. This gives you a better idea of what's at stake for your project and provides an intelligence report on customer psychology, the extent that customers will use the system (use cases), and the visibility of the project to executives. |
|
|
|
|
|
|
|
|
Tip
In the Visual Basic community, it has become normal practice to insert hundreds of lines of code into forms, use highly publicized tips and tricks, and slap together a nice graphical user interface with slick features. The resulting system, typically based on ad hoc assumptions, is deemed to have an architecture. However, this process of developing doesn't lend itself to |
|
|
|
|
|
|